System and method for a distribution manager

ABSTRACT

Embodiments of systems and methods for a distribution manager are presented herein. Specifically, embodiments may receive a request for support for a mobile application and determine a platform server to support the mobile application based on capacity data associated with a set of platform servers in an application table associated with the mobile application. Embodiments may also deliver identification of the platform server over the network, the identification of the platform server comprises connectivity information configured to allow the mobile application to connect to the platform server.

RELATED APPLICATIONS

This patent application is a continuation of, and claims a benefit ofpriority under 35 U.S.C. 120 of the filing date of U.S. patentapplication Ser. No. 13/588,307 filed Aug. 17, 2012 entitled “SYSTEM ANDMETHOD FOR A DISTRIBUTION MANAGER”, which in turn claims the benefit ofpriority under 35 U.S.C. 119 to U.S. Provisional Patent Application Ser.No. 61/528,858, filed Aug. 30, 2011 entitled “SYSTEM AND METHOD FORCLOUD DISTRIBUTION MANAGER,” and U.S. Provisional Patent ApplicationSer. No. 61/531,463, filed Sep. 6, 2011, entitled “SYSTEM AND METHOD FORCLOUD DISTRIBUTION MANAGER,” which are incorporated herein in theirentirety by reference.

TECHNICAL FIELD

This disclosure relates generally to the deployment of network basedapplications. Specifically, this disclosure relates to the dynamicassignment and provisioning of platforms to support deployedapplications in a mobile environment.

BACKGROUND

In recent years the increasing prevalence of applications for mobiledevices has led to greater amounts, and more varied amounts, of datatraffic communicated through networks and a greater load on theplatforms that support these applications. Further, differentapplications may have different usage profiles, with certainapplications having large surges of usages during particular timeperiods but relatively little usage at other times. Other applicationsmay have a relative constant usage.

Platforms that support mobile applications may, however, have a finitecapacity. This capacity may be exceeded, especially in times of highdemand. However, it is an inefficient and perhaps costly use ofresources to deploy additional platforms to support peak usage of theapplication if those platforms will be underutilized once the peakdemand subsides.

Accordingly, it is desired to dynamically and efficiently deploy anddeprecate platforms for mobile applications and dynamically route thosemobile applications to the various deployed platforms to achieve avariety of desired goals.

SUMMARY

Different applications may have different usage profiles, and forcertain applications it may be difficult to determine how many users maychoose to use a mobile application at any given time. Issues may arisewhen there are more users desiring to utilize an application than aplatform will support, when trying to efficiently determine a number ofplatforms to support an application, when routing users to platforms orfor other reasons.

Embodiments of systems and methods for a distribution manager arepresented herein. Specifically, embodiments may receive a request forsupport for a mobile application and determine a platform server tosupport the mobile application based on capacity data associated with aset of platform servers in an application table associated with themobile application. Embodiments may also deliver identification of theplatform server over the network, the identification of the platformserver comprises connectivity information configured to allow the mobileapplication to connect to the platform server.

More specifically, in certain embodiments, a distribution manager mayselect a platform to support an application, divert an application toanother platform or deliver a message that there are currently no otheravailable platforms, efficiently manage the loads of platformssupporting an application, instantiate new platforms supporting theapplication, deprecate platforms supporting the application or performother actions.

In an embodiment, the request for support is received after a timeperiod has elapsed or if connectivity between the mobile application andthe platform cannot be established.

In an embodiment, if the connectivity between the mobile and theplatform cannot be established the instructions are configured todetermine a new platform to support the mobile application.

In an embodiment, the capacity data is associated a total number ofusers each platform within the set can support and a number of usersassigned to each platform within the set.

An embodiment may create a new platform if a capacity thresholdassociated with the platform and the capacity data is exceeded.

An embodiment may deprecate a platform within the set of platforms basedon the capacity data for the set of platforms.

An embodiment may determine that a version of the mobile application isnot the most up to date version of the mobile application, and deliveran update of the mobile application.

In an embodiment, the request includes a device identifier, and theembodiment may compare the device identifier with identifiers within theapplication table to determine whether to assign the platform to themobile application.

These, and other, aspects of the invention will be better appreciatedand understood when considered in conjunction with the followingdescription and the accompanying drawings. The following description,while indicating various embodiments of the invention and numerousspecific details thereof, is given by way of illustration and not oflimitation. Many substitutions, modifications, additions orrearrangements may be made within the scope of the invention, and theinvention includes all such substitutions, modifications, additions orrearrangements.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a block diagram illustrating one embodiment of a topologyof a network.

FIG. 2A depicts a block diagram illustrating one embodiment of atopology of with a distribution manager.

FIG. 2B depicts an embodiment of a method for the deployment of a mobileapplication.

FIG. 2C depicts an embodiment of a method for the deployment of a mobileapplication.

FIG. 3A depicts a block diagram illustrating one embodiment of atopology with a distribution manager.

FIG. 3B depicts an embodiment of a method utilized by a distributionmanager for directing applications to a platform.

FIG. 4A depicts a block diagram illustrating one embodiment of atopology with a distribution manager.

FIG. 4B depicts an embodiment of a method utilized by a distributionmanager for directing applications to a platform.

FIG. 5A depicts a block diagram illustrating one embodiment of atopology with a distribution manager.

FIG. 5B depicts an embodiment of a method utilized by a distributionmanager for indicating that there are no available platforms.

FIG. 6A depicts a block diagram illustrating one embodiment of atopology with a distribution manager.

FIG. 6B depicts an embodiment of a method utilized by a distributionmanager for directing licensed applications.

FIG. 7A depicts a block diagram illustrating one embodiment of atopology with a distribution manager.

FIG. 7B depicts an embodiment of a method utilized by a distributionmanager for a security feature.

FIG. 8 depicts one embodiment of an application table.

DETAILED DESCRIPTION

The invention and the various features and advantageous details thereofare explained more fully with reference to the nonlimiting embodimentsthat are illustrated in the accompanying drawings and detailed in thefollowing description. Descriptions of well-known starting materials,processing techniques, components and equipment are omitted so as not tounnecessarily obscure the invention in detail. It should be understood,however, that the detailed description and the specific examples, whileindicating preferred embodiments of the invention, are given by way ofillustration only and not by way of limitation. Various substitutions,modifications, additions and/or rearrangements within the spirit and/orscope of the underlying inventive concept will become apparent to thoseskilled in the art from this disclosure. Embodiments discussed hereincan be implemented in suitable computer-executable instructions that mayreside on a computer readable medium (e.g., a hard disk (HD)), hardwarecircuitry or the like, or any combination.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, article, orapparatus. Further, unless expressly stated to the contrary, “or” refersto an inclusive or and not to an exclusive or. For example, a conditionA or B is satisfied by any one of the following: A is true (or present)and B is false (or not present), A is false (or not present) and B istrue (or present), and both A and B are true (or present).

Additionally, any examples or illustrations given herein are not to beregarded in any way as restrictions on, limits to, or expressdefinitions of, any term or terms with which they are utilized. Instead,these examples or illustrations are to be regarded as being describedwith respect to one particular embodiment and as illustrative only.Those of ordinary skill in the art will appreciate that any term orterms with which these examples or illustrations are utilized willencompass other embodiments which may or may not be given therewith orelsewhere in the specification and all such embodiments are intended tobe included within the scope of that term or terms. Language designatingsuch nonlimiting examples and illustrations includes, but is not limitedto: “for example,” “for instance,” “e.g.,” “in one embodiment.”

Embodiments of the present invention can be implemented in a computercommunicatively coupled to a network (for example, the Internet, anintranet, an internet, a WAN, a LAN, a SAN, etc.), another computer, orin a standalone computer. As is known to those skilled in the art, thecomputer can include a central processing unit (“CPU”) or processor, atleast one read-only memory (“ROM”), at least one random access memory(“RAM”), at least one hard drive (“HD”), and one or more input/output(“I/O”) device(s). The I/O devices can include a keyboard, monitor,printer, electronic pointing device (for example, mouse, trackball,stylus, etc.), or the like. In embodiments of the invention, thecomputer has access to at least one database over the network. In anembodiment, the database may be located on the same physical hardware asa platform server, and may be accessed locally through protocols such asbut not limited to open database connectivity (ODBC).

ROM, RAM, and HD are computer memories for storing computer-executableinstructions executable by the CPU or capable of being compiled orinterpreted to be executable by the CPU. Within this disclosure, theterm “computer readable medium” is not limited to ROM, RAM, and HD andcan include any type of data storage medium that can be read by aprocessor. For example, a computer-readable medium may refer to a datacartridge, a data backup magnetic tape, a floppy diskette, a flashmemory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, orthe like. The processes described herein may be implemented in suitablecomputer-executable instructions that may reside on a computer readablemedium (for example, a disk, CD-ROM, a memory, etc.). Alternatively, thecomputer-executable instructions may be stored as software codecomponents on a DASD array, magnetic tape, floppy diskette, opticalstorage device, or other appropriate computer-readable medium or storagedevice.

In one exemplary embodiment of the invention, the computer-executableinstructions may be lines of C++, Java, JavaScript, or any otherprogramming or scripting code. In an embodiment, HTML may utilizeJavaScript to provide a means of automation and calculation throughcoding. Other software/hardware/network architectures may be used. Forexample, the functions of the present invention may be implemented onone computer or shared among two or more computers. In one embodiment,the functions of the present invention may be distributed in thenetwork. Communications between computers implementing embodiments ofthe invention can be accomplished using any electronic, optical, radiofrequency signals, or other suitable methods and tools of communicationin compliance with known network protocols.

Additionally, the functions of the disclosed embodiments may beimplemented on one computer or shared/distributed among two or morecomputers in or across a network. Communications between computersimplementing embodiments can be accomplished using any electronic,optical, radio frequency signals, or other suitable methods and tools ofcommunication in compliance with known network protocols. It will beunderstood for purposes of this disclosure that a module is one or morecomputer processes, computing devices or both, configured to perform oneor more functions. A module may present one or more interfaces which canbe utilized to access these functions. Such interfaces include APIs, webservices interfaces presented for a web services, remote procedurecalls, remote method invocation, etc.

In recent years the increasing prevalence of applications for mobiledevices has led to greater amounts, and more varied amounts, of datatraffic communicated through networks and a greater load on theplatforms that support these applications.

Different applications may have different usage profiles, and forcertain applications it may be difficult to determine how many users maychoose to use a mobile application at any given time. For certainapplications, the number of users may range from a few hundred users tohundreds of thousands of users. Issues may therefore arise when thereare more users desiring to utilize an application than a platform willsupport, when trying to efficiently determine a number of platforms tosupport an application, or when routing users to platforms.

Embodiments disclosed herein provide for a distribution manager thatselects a platform to support an application, diverts an application toanother platform or delivers a message that there are currently no otheravailable platforms, and efficiently manages the loads of platformssupporting an application, instantiates new platforms supporting theapplication or deprecates platforms supporting the application.

Accordingly, the distribution manager may be a fully automated systemthat can dynamically and efficiently deploy and deprecate platforms formobile applications and dynamically route those applications to thevarious deployed platforms to achieve a variety of desired goals,including for example, load balancing, lower cost, better service,enhanced security, licensing controls, efficient application updates,disaster recovery, or a wide variety of other goals.

Before turning to specific embodiments as disclosed herein, a generaldiscussion of platforms supporting mobile applications may prove useful.FIG. 1 depicts one embodiment of topology 100 used for the deployment ofan application on a mobile device 110.

The topology 100 includes one or more mobile devices 110 connected toone or more platforms 120 over a network 130.

The network 130 may be a wired or wireless network such as the Internet,an intranet, a LAN, a WAN, a cellular network, another type of network.It will be understood that network 130 may be a combination of multipledifferent kinds of wired or wireless networks.

Mobile devices 110 may be smart phones, laptop computers, personal dataassistants or any other type of device that can process instructions andconnect to network 130 or one or more portions of network 130.

Each platform 120 may be a general platform server that is capable ofsupporting multiple server applications 122 (which may be one or moremodules), and each platform 120 may include one or more serverapplications 122 addressable at a single location. The serverapplications 122 of a particular platform 120 may be deployed onphysical computing devices residing at a particular location (such asthose associated with the provider of a particular mobile application)or may be deployed in a cloud 140.

Cloud 140 may be, for example, a cloud such as the Amazon ElasticCompute Cloud (EC2). Thus, when a platform 120 is deployed in the cloud140, the server application(s) may be executing on a virtual machineprovided in the cloud, where the virtual machine is addressable at asingle location.

Regardless of the location of the platform 120, the server applicationsof a platform 120 may be used to support one or more applications 112deployed on a mobile device 110. More specifically, an application 112deployed on a mobile device 110 may contact a particular platform 120,in return the platform 120 returns content or other data to theapplication on the mobile device 110 where it may be rendered forpresentation to the user, or used in other functionality performed bythe application on the mobile device 110. The application on the mobiledevice, in turn, may filter content, render content for presentation tothe user, or be used in other functionality performed by the application112 on the mobile device 110.

As discussed above, the increasing prevalence of applications, includingthose for mobile devices, has led to greater, and more varied, amountsof data traffic communicated through networks and a greater load on theplatforms that support these applications. Furthermore, differentapplications may have different usage profiles.

Platforms that support mobile application may, however, have a finitecapacity (for example, in total number of applications simultaneouslyconnected to the platform or requests from applications that can besimultaneously serviced, etc.). This capacity may be exceeded,especially in times of high demand. However, it as an inefficient andperhaps costly use of resources to deploy additional platforms tosupport peak usage of the application if those platforms will beunderutilized once the peak demand subsides. Furthermore, the deploymentof additional platforms does nothing to protect against the failure of aplatform. If a mobile application is configured to contact a particularplatform and the platform fails, all the mobile applications configuredto contact that platform may be without service. Accordingly, amongother things, it is desired to dynamically and efficiently deploy anddeprecate platforms for a mobile applications and dynamically routethose applications to the various deployed platforms to achieve avariety of desired goals, including for example, load balancing, lowercost, better service, enhanced security, licensing controls, efficientapplication updates, disaster recovery, or a wide variety of othergoals.

Attention is thus directed to embodiments of systems and methods for adistribution manager. More specifically, embodiments of such adistribution manager may maintain a list of deployed platformsassociated with mobile applications. As understood in this disclosurethe term platform may refer to a deployed mobile application and theplatform servers supporting that deployed mobile application.

In one embodiment, the distribution manager may serve as a contact pointfor deployed mobile applications. When contacted by a mobile applicationthe distribution manager may return a particular platform server to theapplication based on a variety of criteria. The application can thencontact that platform server to obtain service. The distribution managermay maintain a measure of the load on the deployed platform servers(e.g., number of users in total on each platform server, maximum on aparticular platform server, number of users currently on every or one ormore of the deployed platform servers, etc.) and deploy additionalplatform servers to support that application or deprecate currentlydeployed platform servers based on this load measure. It will be notedthat the distribution manager may simultaneously perform theseoperations for multiple different deployed platforms.

Moving now to FIG. 2A, one embodiment of a topology for the deploymentof a mobile application 211 that includes a distribution manager 250 isdepicted. The mobile application 211 may be appropriately configured toexecute on mobile device 210 on which it is deployed and comprise aninterface for interacting with the mobile application 211 or the mobiledevice 210.

Platform server 221 may be a multi-tenant server configured tocommunicate with any number of integrated servers. Each platform server221 may be associated with at least one application 211. Platform server221 may support a mobile application 211 as well as provide content tobe displayed by mobile application 211. Platform server 221 maysimultaneously host a plurality of mobile applications 211 associatedwith different servers.

Distribution manager 250 comprises one or more server applications(e.g., modules) accessible over a network (e.g., using HTTP or anotherprotocol) that may implement the functionality discussed here. Thedistribution manager 250 may be deployed in the cloud 140 (e.g., on avirtual machine in the cloud 140) or be deployed on one or more platformservers 221 associated with the site of a provider of the mobileapplication 211. Hereinafter, the distribution manager 250 will bereferred to as a cloud distribution manager (CDM), it will however beunderstood that this nomenclature is utilized solely for the sake ofconvenience and that any and all functionality discussed with respect tothe CDM 250 may be applied to a distribution manager regardless oflocation. However, in many cases it may be desirable to deploy thedistribution manager 250 in cloud 140 as this may alleviate the effectof any connectivity issues that may affect platforms servers 221deployed at a provider's site. It may also be possible to have multipledeployed distribution managers (e.g., one in the cloud 140 and one at aprovider's site).

CDM 250 may include CDM module 260 and data store 251. CDM module 260may include deployment module 262, platform module 264 and securitymodule 266.

Deployment module 262 may be configured to access an application table252 stored on data store 251 and determine a platform server 221 for amobile application 211 based on a variety of criteria.

Platform module 264 may be configured to instantiate new platformssupporting an application or deprecate platforms supporting theapplication.

Security module 266 may be configured to implement security inconjunction with the CDM 250.

Data store 251 may be a file store, database, memory or some otherstorage medium configured to store data. In data store 251, CDM 250 maymaintain an application table 252 associated with a mobile application211 deployed on mobile devices 210.

This application table 252 may comprise a set of deployed platformservers 221 that support the mobile application 211. Additionalinformation may also be stored in association with the deployedplatforms such as the name of the application 211 deployed on mobiledevice 210, the operating system (OS) associated with the mobile device210 executing application 210, a geographic location associated witheach platform server 221 or the source IP address of the application 211deployed on mobile device 210. The application table 252 may also haveother information such as connectivity data (e.g., IP or http address,port addresses, etc.) of the deployed platforms servers 221 that servicethat application or a status associated with the platform server 221,such as active, deprecated, message, error, etc.

Additionally, the application table 252 may have capacity dataassociated with each platform server 221. This capacity data may be, forexample, the total number of users each platform server 221 can support,the number of users in parallel each platform server 221 can support,the number of users assigned to a particular platform server 221, thenumber of users currently on a given platform server 221, etc.

This capacity information may be configured manually by, for example, anadministrator, or may be determined automatically, for example, bycontacting a platform server 221 or having each platform server 221notify CDM 250 of its current usage at a particular time interval. Whena particular user is assigned to a particular platform server 221 thecapacity data (e.g., number of users assigned to a platform server 221)may be updated.

In one embodiment, the capacity information may be associated withprocessing capabilities for platform server 221 and application 211. Forexample, platform server 221 may be configured to support application211. As a result of the type of application or the manner in whichapplication 221 is being supported by platform server 221 may causeplatform server 221 to reach a utilization metric, which may beassociated with processing power, memory, or disk utilization ofplatform server 221. Based on a total number of users for application211 assigned to platform server 221 when the utilization metric isreached, platform server 221 may determine the total number of users itcan support. Platform server 221 may then deliver the capacityinformation to CDM 250.

The application table 252 may also have cost information associated witha deployed platform server 221. For example, platform servers 221 thatare deployed in the cloud 140 may be expensive as the providers of themobile application 211 may be charged for their use by the providers ofthe cloud 140. In contrast, a platform server 221 deployed on thephysical servers already owned by the providers of the mobileapplication 211 may be relatively low cost. Thus, cost information maybe associated with a platform server 221. It will be noted that thiscost information may be the same as the location of the platform server221 or other data associated with the platform server 221.

Mobile application 211 may be a module on a mobile device 210 configuredto allow an end user to perform an activity, such as accessing ormanipulating data, including for example track and display particularnews stories, communicate emails, etc. The mobile application 211 may beconfigured with the location (e.g., such as a Uniform Resource Locator(URL) address) of the CDM 250. The mobile application 211 may thus beconfigured to contact CDM 250 based on one or more conditions. Forexample, the mobile application 211 may be configured to contact the CDM250 on initial startup of the mobile application 211, every time themobile application is started or executed, after the expiration of acertain time period (e.g., 7 days, every day, etc.), when connectivityissues occur with a platform server 221, some combination thereof, orbased on some other condition or criteria, etc.

In one embodiment, then, when a mobile application 211 is initiallystarted for the first time (e.g., after installation) it may contact theCDM 250, where the contact may be, for example, a request including datasuch as an identifier of the mobile application 211, the name of theapplication 211 deployed on mobile device 211, the operating system (OS)associated with the mobile device 210 executing application 211, alanguage associated with the mobile device 210, geographical informationof the mobile device 210, the source IP address of the application 211deployed on mobile device 210 or other data.

In return, the CDM 250 may access the application table 252 anddetermine a platform server 221 for the mobile application 211 based ona variety of criteria. In one embodiment, deployment module 262 maydetermine a platform server 221 associated with the application 211based on one or more criteria associated with the capacity of each ofthe deployed platform servers 221 in the application table 252associated with the application 211. The determined platform server 221can be returned to the application 211 where it may be stored andutilized by the application 211.

Specifically, in one embodiment, the CDM module 260 may pass the IPaddress and ports of the selected platform server 221 back to mobileapplication 211. The mobile application 211 can then contact theselected platform server 221 for service (e.g., to provide content orother data to the mobile application 211). Deployment module 260 maythen deliver an instruction to add the details associated with theselected server 221 and the mobile application 210 assigned to theselected platform server 221 to the application table 252. The selectedplatform server 221 to support the mobile application 211 may beselected by the CDM module 260 according to a wide variety of criteria.

In one embodiment, deployment module 262 may select the platform server221 based on one or more criteria associated with the capacity of eachof the deployed platform servers 221 in the application table 252. Forexample, the percentage of total capacity of users currently assigned tothe platform or a percentage of the current capacity available at theplatform server 221.

In another embodiment, deployment module 262 may determine the platformserver 221 based on one or more criteria associated with the cost ofeach of the deployed platform servers 221 in the application table 252.For example, a low cost platform server 221 may be determined for amobile application 211, if the low cost platform server 221 still hascapacity regardless of the number of users on that platform server 221or higher cost platform servers 221.

In one embodiment, deployment module 262 may determine a platform server221 based on the nearest (either geographically or logically) availableplatform server 221 to the mobile device as determined by the locationof the platform servers 221 and the location information for the mobiledevice 210 received in the request. Deployment module 262 may determinethe location of the platform servers 221 via the application table 252.Deployment module 262 may determine which available platform server 221is closest to the location information delivered in the request. Then,deployment module 262 may select the closest platform server 221 to themobile device 210.

In another embodiment, deployment module 262 may determine a platformserver 221 based on the language associated with the mobile device 210or mobile application 211. In this example, deployment module 262 mayaccess the application table 252 to determine if a platform server 221supports the language of the mobile device 221 that delivered therequest. If so, deployment module 262 may select a platform server 221supporting the language of the mobile device 210.

In another embodiment, deployment module 262 may determine a platformserver 221 based on the version number associated with the mobileapplication 211. In this example, deployment module 262 may access theapplication table 252 to determine if a platform server 221 supports theversion number of the mobile application 211 delivered in the request.If so, deployment module 262 may select a platform server 221 supportingthe version number of the mobile application 211. In this embodiment,the platform server 221 supporting the version number of the mobileapplication 211 may be specifically configured to support the versionnumber of the mobile application 211.

In another embodiment, deployment module 262 may select a platformserver 211 based on the OS of the mobile device 210. In this example,the application table 252 may be accessed by deployment module 262 todetermine if a platform server 221 supports the OS of the mobile device211 delivered in the request. If so, deployment module 262 may select aplatform server 221 supporting the OS of the mobile device 210. In thisembodiment, the platform server 221 supporting the OS of the mobiledevice 210 may be specifically configured to support the OS of themobile device 210.

In view of the above, one skilled in the art will appreciate thatdeployment module 262 may determine a platform server 221 based onalmost any criteria or combination of criteria desired, including forexample, any information associated with the mobile device 210,application 211 and/or platform server 221, etc.

As mentioned above, once a platform server 221 is determined for themobile application 211 it may be returned to the mobile application 211and the mobile application 211 can then contact the selected platformserver 221 for service (e.g., to provide content or other data to themobile application 12). The mobile application 211 may continue tocontact the selected platform server 221 for service up until theoccurrence of one or more conditions such as a time period havingelapsed since the mobile application last contacted the selectedplatform server 221 or CDM 250, connectivity with the selected platformserver 221 cannot be established, or the occurrence of anothercondition. At such a point, then, mobile application 211 may contact CDM250, and the deployment module 262 may access the application table 252and determine if the mobile application 211 should continue to contactthe selected platform server 221 or a new platform server 221.

In one embodiment, when the mobile application 211 first contacts theCDM 250, the mobile device 210 executing the application 211 may also beprovided with a cloud identifier. The cloud identifier may be a uniqueidentifier that is not reset, and may persists even if the mobile deviceis later directed to a different platform. The cloud identifier may beused to store user settings associated with the application, such asrefresh rates, display settings, etc., such that if the mobileapplication 211 is later diverted to another platform server 221, theother platform server 221 may include the user's preferences. Data store251 may be updated to include a mapping of the cloud identifier and auser's preferences.

Turning now to creating and deprecating platforms, in one embodiment, ifa certain threshold is exceeded (e.g., user capacity on one computingdevice, all computing devices of a platform server 221, etc.), platformmodule 264 may create or provision a new platform server 221. In anotherembodiment, platform module 264 may create a new platform based onhistorical data or when the number of users on a platform server 221 iswithin some distance of a threshold user capacity. For example, based onadoption rates associated with a platform server 221, platform module264 may predict when the threshold is to be exceeded and create a newplatform server 221 when it is predicted that the threshold will beexceeded.

This creation may be done by CDM 250 contacting cloud 140 to obtain avirtual machine of cloud 140, obtain connectivity data associated with avirtual machine or provide the data to the virtual machine needed tosupport the mobile application 211. In one embodiment, platform module264 may communicate a request to cloud 140 to provision a platformserver 221 to support a number of users using an application 211. Then,based on the request, platform module 264 may deploy a new platformserver 221 to support application 211, obtain the connectivity detailsassociated with the platform server 221, add these details toapplication table 252, and indicate that the status of the new platformserver 221 is available.

Platform module 264 may also create a platform server 221 for theapplication 211 by contacting a deployed platform server 221 used tosupport another mobile application, assigning this platform server 221to support mobile application 211 (instead of, or in addition to, themobile application it is currently supporting) and providing the dataneeded to support the mobile application 211 (or a location where thenewly created platform server 221 can get this data).

In one embodiment, platform module 264 may create a platform server 221based on the location of the mobile device 210 executing the mobileapplication 211. The mobile application 211 may pass the location of themobile device 210 in a communication to the CDM 250. If the mobiledevice 210 is in a location that is remote from a currently deployedplatform server 221, or there are a threshold number of users in acertain geographic area, platform module 264 may deploy a platformserver 221 to support the mobile application 211 that is proximate (orwithin) the geographic area. Thus, service to users in or near thatgeographic may be improved. In other embodiments, new platform servers211 may be created based on thresholds associated with a version numberof the application 211, an OS of the mobile device 220 that application211 is deployed on, a language associated with the application 211, etc.

Platform module 264 may then add the details associated with a newlycreated platform server 221 to the application table 252 and the mobileapplications 210 assigned to this newly created platform server 221.

During any subsequent interaction with the selected platform server 221,mobile application 211 may encounter an issue with that platform server221 (e.g., the platform server 221 failed, capacity is exceeded,excessive delay, etc.). The mobile application 211 may contact the CDM250 to be re-assigned to a different platform server 221 when such anissue is encountered.

In one embodiment, when the mobile application 211 reconnects with theCDM 250 the mobile application 211 may provide details as to the failureencountered with the previously assigned platform server 221 (e.g., thedata originally provided by the CDM 250, the platform server 221 it wasattempting to contact, the application identifier, etc.). CDM 250 mayuse this data for a variety of purposes, for example, it may send amessage to the mobile application 211 or may mark the platform server221 deprecated in the application table 252 such that it is not assignedto any mobile application 211 (as will be discussed in more detaillater). In another embodiment, upon mobile application 211 providing CDM250 with details as to the failure encountered with the previouslyassigned platform server 221, CDM 250 may flag the status of theplatform server 221 within application table 252 to indicate there is adefect with the platform server 221.

If no issues are encountered during a certain time period, the mobileapplication 211 may contact the CDM 250 after the expiration of thattime period and provide details on the previously assigned platformserver 221 (e.g., the data originally provided by the CDM 250, theplatform server 221 connectivity details, the application identifier,etc.). At this point the CDM 250 may reply with a response to theapplication 211 indicating the application should continue to use thatplatform server 221 or may reassign the mobile application 211 toanother platform server 221.

This feature may be useful in the deprecation of platform servers 221.For example, as discussed above, new platform servers 221 may bedeployed by platform module 264 for a number of reasons. It may,however, not be desirable to keep the platform servers 221 deployed,especially in the case when they are underutilized and high cost. Thus,in such cases the platform server 221 may be marked as deprecated(manually by an administrator or by an algorithmic determination carriedout by the CDM 250) in the application table 252.

Accordingly, when a mobile application 211 contacts the CDM 250 if it iscurrently being serviced by a deprecated platform server 221 then it maybe re-assigned to another platform server 221. Additionally, no newmobile applications 211 may be assigned to that platform server 221. Asall mobile applications 211 are configured to contact the CDM 250 afterthe expiration of the same time period, it can be virtually guaranteedthat when a status of a platform server 221 is marked as deprecatedwithin application table 252, no mobile applications 211 may be assignedto that platform server 221 after the expiration of that time period.These deprecated platform servers 221 can then be taken offline, andthat status of the platform servers 221 can be indicated as depreciatedwithin the application table 252.

The CDM 250 may also be used for a number of other purposes. Forexample, the CDM 250 may be used to send messages to mobile devices 210assigned to a particular, or some set of, deployed platform servers 221.In one embodiment, a status of a platform server 221 may be marked as“message” in the application table 252 and a message sent to mobileapplications 211 to contact the CDM 250 and provide connectivityinformation associated with that platform server 221. When such a mobileapplication 211 does contact the CDM 250, this message may be deliveredto the mobile application 211.

Similar methods may be performed to provide an application update to themobile application 211. For example, in one embodiment, CDM module 260may be used to update application 211. When a mobile application 211communicates with CDM 250, CDM module 260 may access application table252 to determine if the most up-to-date version of mobile application211 is deployed on mobile device 210. If the most up to up-to-dateversion of mobile application 211 is not deployed on mobile device 210,CDM module 260 may communicate an update of the mobile application 211to mobile device 210 and correspondingly update application table 252.

In another embodiment, as the CDM 250 may be a central contact point formobile applications 210 it may be useful to implement security inconjunction with the security module 266. To implement such security, adevice identifier (EMEI, id number of SIM card, etc.) associated withmobile devices 210 that are to be allowed to access a mobile applicationmay be stored at the data store 251 in association with the application211 (e.g., in a table associated with the application table). When amobile application 211 contacts the CDM 250 they may provide theidentifier of the device 210 on which it is executing. Security module266 may match the provided identifier with the stored identifiers todetermine whether to assign a platform server 221 to that mobileapplication 211 (and thus whether to support that instance of the mobileapplication). If the identifier of the device 210 is not provided to theCDM 250, security module 266 may block the mobile application fromaccessing a platform server 221. In an embodiment, the device identifiermay be a security certificate that may be stored locally on mobiledevice 210 in the form of a file or other data structure.

In another embodiment, security module 266 may manage licenses assignedto a mobile application 211. A mobile application 211 may have a certainnumber of available licenses that it may be able to support, and once alicense capacity has been exceeded no new users of the mobileapplication may be supported. When a client contacts the CDM 250,security module 266 may access application table 252. Then, securitymodule 266 may sum the total number of users assigned to all theplatforms servers 221 supporting the mobile application 211. Securitymodule 266 may compare the sum of the total number of users assigned toall the platforms to a licensing capacity. If the number of usersassigned to all the platform servers 221 does not exceed the licensingcapacity, deployment module 262 may select a platform server 221 for themobile application 211.

As can be seen then, embodiments as depicted herein may provideon-demand load balancing as load balancing may be dynamicallyaccomplished as mobile applications 211 contact the CDM 250 or asplatform servers 221 fail or are created and deprecated. As the locationof the CDM 250 may be a central contact point and contact is only doneon initial startup, every time the mobile application is started orexecuted, once every time period, etc., this load balancing may beperformed without interposing a device between a mobile application 211and a platform server 221 every time the mobile application 211 contactsthe platform server 221 (as in traditional load balancing). Thus, thisdynamic load balancing may also be accomplished using lower costmachines. In one embodiment, CDM 250 may perform load balancing ofplatform servers 221 supporting mobile application 211 based on a numberof assigned mobile applications 211 to a platform server 221, apercentage of applications 211 assigned to a platform server 221 thatthe platform server 221 can support, language of application 211,location of mobile device 210, version number of application 211, etc.For example in one embodiment of load balancing, CDM 250 may determine anumber of assigned mobile applications 210 to each platform server 221,order the platform servers 221 based on the number of assigned mobileapplications 211, and the next mobile application 211 requesting supportfrom a platform server 210 may be assigned the platform server 221 withthe fewest assigned mobile applications 211.

FIG. 2B depicts an embodiment of a method 270 for the deployment of amobile application using a distribution manager 250.

At step 272, a request may be received from a mobile device for supportfor a mobile application. The request may include, for example, one ormore of an identifier of the mobile application, the name of theapplication deployed on mobile device, the operating system (OS)associated with the mobile device executing application, language of theapplication, version number of the application, a location of the mobiledevice (which may be obtained by any known means such as GPS, WiFidatabase lookup, radio direction finding, etc.), the source IP addressof the application deployed on mobile device, or other information.

In return, at step 274, an application table may be accessed, and anavailable platform server to support the mobile application associatedwith the request may be determined based on one or more criteria. In oneembodiment, the platform server may be determined based on one or morecriteria associated with a capacity of each of the deployed platformservers in the application table. For example, the application table maybe accessed to determine a percentage of total capacity of userscurrently assigned to each platform server supporting the application.The platform server with the lowest percentage of total capacity usersmay be selected.

One skilled in the art will appreciate a platform server may be selectedbased on almost any criteria or combination of criteria desired,including for example, any information associated with the mobiledevice, application or platform server, etc.

Upon determining a platform server, connectivity information, such asthe IP address and ports of the determined platform server may bedetermined based on the connectivity details of the selected platformserver in the application table.

At step 276, connectivity information for the determined platform servercan be delivered to the application where it may be stored.Specifically, in one embodiment, the IP address and ports of thedetermined platform server may be delivered to the mobile applicationassociated with the request.

At step 278, the application table may be updated to include theinformation associated with the mobile application making the requestfor a platform, capacity data associated with adding the mobileapplication to be supported by the determined platform server and thedetails of the determined platform server.

FIG. 2C depicts an embodiment of a method 280 for the deployment of amobile application using a distribution manager.

At step 282, a mobile application executing on a mobile device maycontact a CDM via an address, such as a URL address, of the CDM. Themobile application may contact the CDM on initial startup of the mobileapplication, after the expiration of a certain time period (e.g., 7days, every day, etc.), every time the mobile application is started orexecuted, when connectivity issues occur with a platform, somecombination thereof, or based on some other condition or criteria, etc.

The mobile application may contact the CDM after installation, where thecontact may be, for example, a request including data such as anidentifier of the mobile application, the name of the applicationdeployed on the mobile device, the operating system (OS) associated withthe mobile device executing the application, a language associated withthe mobile device, geographical information of the mobile device, thesource IP address of the application deployed on the mobile device orother data.

At step 284, details associated with a selected platform server tosupport the mobile application may be received. Specifically, the IPaddress and ports of the selected platform server may be received. Theselected platform server may be determined based on a variety ofcriteria. The selected platform server may be determined based on almostany criteria or combination of criteria desired, including for example,any information associated with the mobile device, application and/orplatform server, etc.

At step 286, the details associated with the selected platform server tosupport the mobile application may be stored in a memory accessible bythe mobile application. The stored details may include the IP addressand ports of the selected platform server.

At step 288, the mobile application may contact the selected platformserver for service to use the mobile application. The platform servermay provide content or other data to the mobile application.

At step 290, it may be determined if a time period has elapsed since themobile application last contacted the CDM. In one embodiment, the timeperiod may be any length of time such as 7 days, every day, etc. If itis determined at step 290 that the time period has elapsed since themobile application last contacted the CDM, then the mobile applicationmay return to step 282 and contact the CDM.

If it is determined at step 290 that the time period has not elapsedsince the mobile application last contacted the CDM, then at step 292 itmay be determined if there is an error in connectivity between themobile application and the selected platform. It may be determined thatthere is an error in connectivity between the mobile application and theselected platform server if connectivity with the selected platformserver cannot be established due to, for example, platform failure,exceeding the capacity of the selected platform server, excessive delay,etc.

If it is determined at step 292 that there is an error in connectivitybetween the mobile application and the selected platform, then themobile application may return to step 282 and contact the CDM. If it isdetermined at step 292 that there are no errors in connectivity betweenthe mobile application and the selected platform, the mobile applicationmay continue to contact the selected platform for service and return tostep 288.

Turning now to FIGS. 3A and 3B, a block diagram 301 (FIG. 3A) and amethod 302 (FIG. 3B) of a mobile application for a mobile device 305being directed to a platform 321 by CDM 350 is depicted according to oneembodiment. Elements of FIG. 3A may be similar to the elements describedabove and thus may not be explained in more detail.

At step 310, a request may be received from a mobile device for supportfor a mobile application. The request may include an identifier of themobile application, the name of the application deployed on the mobiledevice, the operating system (OS) associated with the mobile deviceexecuting the application, the language of the application, the versionnumber of the application, a location of the mobile device (which may beobtained by any known means such as GPS, WiFi database lookup, radiodirection finding, etc.) and/or the source IP address of the applicationdeployed on mobile device.

In response, at step 315, an application table may be accessed, and anavailable platform server to support the mobile application associatedwith the request may be selected based on a variety of criteria. In oneembodiment, the platform server may be selected based on one or morecriteria associated with a capacity of each of the deployed platformservers in the application table. For example, the application table maybe accessed to determine a percentage of total user capacity currentlyassigned to each platform server supporting the application. Theplatform server with the lowest percentage of total capacity users maybe selected.

In one embodiment, the selected platform server may be based on thenearest available platform to the mobile device as determined by thegeographic location of the platform servers and the location informationreceived in the request. The application table may be accessed todetermine which available platform server is closest to the locationinformation delivered in the request. Then the closest platform serverto the mobile device may be selected.

In another embodiment, a platform server may be selected based on thelanguage associated with the mobile device. In this example, theapplication table may be accessed to determine if a platform serversupports the language of the mobile device delivered in the request. Ifso, a platform server supporting the language of the mobile device maybe selected.

One skilled in the art will appreciate a platform server may be selectedbased on almost any criteria or combination of criteria desired,including for example, any information associated with the mobiledevice, application and/or platform server, etc.

Upon selecting a platform server, connectivity information, such as theIP address and ports of the selected platform server, may be determinedbased on the connectivity details of the selected platform server in theapplication table.

At step 320, connectivity information for the selected platform servercan be delivered to the mobile application where it may be stored.Specifically, in one embodiment, the IP address and ports of theselected platform server may be delivered to the mobile applicationassociated with the request.

At step 325, the application table may be updated to include theinformation associated with the mobile application making the requestfor a platform, capacity data associated with adding the mobileapplication to be supported by the selected platform server and thedetails of selected platform server.

At step 335, the mobile application can then contact the selectedplatform server for service (e.g., to provide content or other data tothe mobile application) using the connectivity information for theselected platform.

The mobile application may continue to contact that platform server forservice up until 1) a time period has elapsed since the mobileapplication last contacted the CDM 350, 2) connectivity with platformserver cannot be established, or 3) the mobile application is started orexecuted again. At this point, the mobile application may reconnect withthe CDM 350.

Turning now to FIGS. 4A and 4B, a block diagram 401 (FIG. 4A) and amethod 402 (FIG. 4B) of a mobile application on a mobile device 405being directed to a platform 421 by CDM 450 is depicted according to oneembodiment. Elements of FIG. 4A may be similar to the elements describedabove and thus may not be explained in more detail.

At step 410, during any interaction with the selected platform server, amobile application may encounter an issue with that platform server(e.g., the platform failed, capacity is exceeded, excessive delay,etc.).

At step 420, a message that an error was experienced between the mobileapplication and platform server may be received. The message may be arequest to be re-assigned to a different platform server. The messagemay include details of the failure encountered with the previouslyassigned platform server, and details of the previously assignedplatform such as an identifier of the mobile application, the name ofthe application deployed on the mobile device, the operating system (OS)associated with the mobile device executing the mobile application, thelanguage of the application, the version number of the mobileapplication, the source IP address of the application deployed on themobile device, and/or the IP address and port number of the platformserver it was attempting to contact.

In response, at step 430, an application table may be accessed todetermine a different platform server for the mobile application basedon a variety of criteria. In one embodiment, the platform server may beselected based on one or more criteria associated with the capacity ofeach of the deployed platform servers in the application table. Forexample, the percentage of total user capacity currently assigned to theplatform server.

Connectivity information for the selected platform server can bedelivered to the application where it may be stored. Specifically, inone embodiment, the IP address and ports of the selected platform servermay be delivered to the mobile application associated with theindication of the error. The application table may be updated to includethe information associated with the mobile application making therequest for a new platform and the selected platform, such as capacitydata associated with selected platforms servicing the mobileapplication.

However, if it is determined that there are no available platformservers that can support the mobile application because each of thecurrent platform servers are at capacity, or any other reason, it may bedetermined that the mobile application should continue to use thecurrent selected platform for support. Thus, at step 430 a response maybe delivered to the mobile application instructing the mobileapplication to continue to use the currently selected platform server.The response may include the IP address and ports of the currentplatform server.

At step 440, the mobile application can then contact the selectedplatform server for service (e.g., to provide content or other data tothe mobile application) using the connectivity information for theselected platform server. The mobile application may continue to contactthat platform server for service up until, for example, 1) a time periodhas elapsed since the mobile application last contacted the CDM, 2)connectivity with platform server cannot be established or 3) the mobileapplication is started or executed again.

Turning now to FIGS. 5A and 5B, a block diagram 501 (FIG. 5A) and amethod 502 (FIG. 5B) of a CDM 550 indicating that there are no platformservers 521 available to service a mobile application on mobile device505 is depicted according to one embodiment. Elements of FIG. 5A may besimilar to the elements described above and thus may not be explained inmore detail.

At step 510, a request may be received from a mobile device for supportfor the mobile application. The request may include an identifier of themobile application, the name of the application deployed on mobiledevice, the operating system (OS) associated with the mobile deviceexecuting the application, the language of the application, stylepresentation preferences, the version number of the application, and/orthe source IP address of the application deployed on the mobile device.

In response, at step 515, an application table may be accessed, and itmay be determined that there are no available platform servers tosupport the mobile application associated with the request. For example,the application table may be accessed to determine platform serverssupporting the requested application. However, upon accessing theapplication table it may be determined that all of the platform serverssupporting the requested application are at capacity.

Thus, it may be determined that platform servers supporting the mobileapplication do exist but have a status “message” within the applicationtable. The status “message” entry within the application table for aplatform server may indicate that a message should be delivered to themobile device associated with the mobile application to be displayed toa user. In such an embodiment, the message may be a service message. Forexample, a service message may state that “The system is currentlyundergoing scheduled maintenance—Please try again in 30 minutes.” In oneembodiment, the application table may be accessed to determine theuser's local language settings associated with the mobile applicationsent in the request at step 510. If the language setting received in therequest is not recognized, then a default language or message may beused or a language may be determined based on location information sentin the request message. An appropriate language associated with thelocation of the mobile device may then be used in the message.

At step 520, the service message may be delivered to the mobileapplication. The service message may be delivered to the source IPaddress of the application deployed on the mobile device.

At step 530, the service message may be displayed on an interface on themobile device. In one embodiment, the message may be sent and displayedcorresponding to presentation information as indicated in the requestmessage for the mobile application. In an embodiment, after presentingthe message on the interface of the mobile device, the application mayprovide means for the user to exit the mobile application.

Turning now to FIGS. 6A and 6B, a block diagram 601 (FIG. 6A) and amethod 602 (FIG. 6B) of a CDM 650 directing a licensed mobileapplication on a mobile device 605 to a platform server 621 are depictedaccording to one embodiment. Elements of FIG. 6A may be similar to theelements described above and thus may not be explained in more detail.

At step 610, a request may be received from a mobile device for supportfor the mobile application. The request may include an identifier of themobile application, the name of the application deployed on mobiledevice, the operating system (OS) associated with the mobile deviceexecuting the application, the language of the application, stylepresentation preferences, the version number of the application, and/orthe source IP address of the application deployed on mobile device.

In response, at step 620, an application table may be accessed, forexample, to determine if the licensing capacity has been exceeded. Byaccessing the application table, the available platforms servers thatsupport the mobile application, the applications each platform serversupports, and the number of users assigned to each application on eachplatform server may also be determined. Then, the users assigned to allthe platform servers supporting the mobile application may be summed.The sum of the total number of users assigned to all the platformservers may be compared to a licensing capacity. The licensing capacitymay indicate a total number of users that may be assigned to platformservers supporting the mobile application at a given time.

If the number of users assigned to all the platform servers does notexceed the licensing capacity, the platform server for the mobileapplication associated with the request may be selected based on avariety of criteria. In one embodiment, the platform server with thelowest percentage of total user capacity currently assigned thatsupports the application may be selected.

If at step 620 it is determined that the number of users assigned to allthe platform servers does not exceed the licensing capacity, thenconnectivity information for the selected platform server can bedelivered to the application where it may be stored. Specifically, inone embodiment, the IP address and ports of the selected platform servermay be delivered to the mobile application associated with the request.The application table may be updated to include information associatedwith the mobile application making the request and the selected platformserver.

At step 630, the mobile application can then contact the selectedplatform server for service (e.g., to provide content or other data tothe mobile application) using the connectivity information for theselected platform server. The mobile application may continue to contactthat platform for service up until, for example, (1) a time period haselapsed since the mobile application last contacted the CDM, (2)connectivity with platform server cannot be established or (3) themobile application is started or executed again.

Returning to step 620, if it is determined that the number of usersassigned to all the platform servers exceeds the licensing capacity, atstep 620 a message can be delivered to the mobile device associated withthe mobile application to be displayed to a user. In one embodiment, themessage may be a service message. For example, a message may indicatethat “There is no available license capacity to support your request.”

Then, at step 640, a mobile device may receive the message, and displaythe text associated with the message. In an embodiment, after presentingthe message on a display of the mobile device, the application mayprovide means for the user to exit the mobile application.

Turning now to FIGS. 7A and 7B, a block diagram 701 (FIG. 7A) and amethod 702 (FIG. 7B) of a security feature of CDM 750 is depicted.Elements of FIG. 7A may be similar to the elements described above andthus may not be explained in more detail.

At step 710, a request may be received from a mobile device for supportfor a mobile application. The request may include a mobile deviceidentification (such as a phone number, international mobile equipmentidentity (EMEI), id number of SIM card, etc.), an identifier of themobile application, the name of the application deployed on the mobiledevice, the operating system (OS) associated with the mobile deviceexecuting application, the language of the application, stylepresentation preferences, the version number of the application, and/orthe source IP address of the application deployed on mobile device.

In response, at step 720, an application table may be accessed todetermine access permissions. The application table may be accessed todetermine what mobile identifiers are allowed to access which platformservers. If the mobile identification associated with the requestmatches a corresponding identifier in the application table, it may bedetermined that the mobile device identification may access a platformserver to support an application.

If at step 720 it is determined that the mobile device may access aplatform server to support the application, then a platform serverdesignated to support the mobile identifier for the mobile applicationmay be selected.

Connectivity information for the selected platform server can bedelivered to the application where it may be stored. Specifically, inone embodiment, the IP address and ports of the selected platform servermay be delivered to the mobile application associated with the request.The application table may be updated to include the informationassociated with the mobile application making the request for a platformand the selected platform.

At step 730, the mobile application can then contact the selectedplatform server for service (e.g., to provide content or other data tothe mobile application) using the connectivity information for theselected platform. The mobile application may continue to contact thatplatform server for service up until, for example, 1) a time period haselapsed since the mobile application last contacted the CDM, 2)connectivity with platform server cannot be established, or 3) themobile application is started or executed again.

Returning to step 720, if it is determined that the mobile deviceidentifier is not associated with a mobile device that may access aplatform server to support the mobile application, a message may bedelivered to the mobile device associated with the mobile application.The message may be configured to be displayed on a display of the mobiledevice. For example, a message may indicate that “The mobile device youare using is not authorized to access the services requested. Pleasecontact the help desk.” In one embodiment, the message may be sent anddisplayed corresponding to presentation information as indicated by therequest message for the mobile application.

Then, at step 740, a mobile device may receive the message, and displaythe text associated with the message. In an embodiment, after presentingthe message on a display of the mobile device, the application mayprovide means for the user to exit the mobile application.

FIG. 8 depicts a table 800 illustrating one embodiment of an applicationtable. Looking now at FIG. 8, column 805 represents an identificationnumber of a platform, columns 810 represents a host IP address of theplatform, columns 815 and 820 represent port addresses of the platform,column 825 represent an application name supported by the platform,column 830 represent the maximum number of users for the applicationthat the platform can support, column 835 represents the number ofcurrently assigned users to the platform for the application, column 840may represent the status of the platform, column 845 may be associatedwith when the platform was created, column 850 represents who authorizedthe platform to be created, column 855 may be associated with when theplatform was updated, column 860 represents who authorized the platformto be updated, column 865 represents a message text to be returned tothe application and displayed on the mobile device if the status fieldof column 840 is set to “message.”

In the foregoing specification, the invention has been described withreference to specific embodiments. However, one of ordinary skill in theart appreciates that various modifications and changes can be madewithout departing from the scope of the invention. Accordingly, thespecification and figures are to be regarded in an illustrative ratherthan a restrictive sense, and all such modifications are intended to beincluded within the scope of invention.

Although the invention has been described with respect to specificembodiments thereof, these embodiments are merely illustrative, and notrestrictive of the invention. The description herein of illustratedembodiments of the invention is not intended to be exhaustive or tolimit the invention to the precise forms disclosed herein (and inparticular, the inclusion of any particular embodiment, feature orfunction is not intended to limit the scope of the invention to suchembodiment, feature or function). Rather, the description is intended todescribe illustrative embodiments, features and functions in order toprovide a person of ordinary skill in the art context to understand theinvention without limiting the invention to any particularly describedembodiment, feature or function. While specific embodiments of, andexamples for, the invention are described herein for illustrativepurposes only, various equivalent modifications are possible within thespirit and scope of the invention, as those skilled in the relevant artwill recognize and appreciate. As indicated, these modifications may bemade to the invention in light of the foregoing description ofillustrated embodiments of the invention and are to be included withinthe spirit and scope of the invention. Thus, while the invention hasbeen described herein with reference to particular embodiments thereof,a latitude of modification, various changes and substitutions areintended in the foregoing disclosures, and it will be appreciated thatin some instances some features of embodiments of the invention will beemployed without a corresponding use of other features without departingfrom the scope and spirit of the invention as set forth. Therefore, manymodifications may be made to adapt a particular situation or material tothe essential scope and spirit of the invention.

Reference throughout this specification to “one embodiment,” “anembodiment,” or “a specific embodiment” or similar terminology meansthat a particular feature, structure, or characteristic described inconnection with the embodiment is included in at least one embodimentand may not necessarily be present in all embodiments. Thus, respectiveappearances of the phrases “in one embodiment,” “in an embodiment,” or“in a specific embodiment” or similar terminology in various placesthroughout this specification are not necessarily referring to the sameembodiment. Furthermore, the particular features, structures, orcharacteristics of any particular embodiment may be combined in anysuitable manner with one or more other embodiments. It is to beunderstood that other variations and modifications of the embodimentsdescribed and illustrated herein are possible in light of the teachingsherein and are to be considered as part of the spirit and scope of theinvention.

In the description herein, numerous specific details are provided, suchas examples of components and/or methods, to provide a thoroughunderstanding of embodiments of the invention. One skilled in therelevant art will recognize, however, that an embodiment may be able tobe practiced without one or more of the specific details, or with otherapparatus, systems, assemblies, methods, components, materials, parts,and/or the like. In other instances, well-known structures, components,systems, materials, or operations are not specifically shown ordescribed in detail to avoid obscuring aspects of embodiments of theinvention. While the invention may be illustrated by using a particularembodiment, this is not and does not limit the invention to anyparticular embodiment and a person of ordinary skill in the art willrecognize that additional embodiments are readily understandable and area part of this invention.

Any suitable programming language can be used to implement the routines,methods or programs of embodiments of the invention described herein,including C, C++, Java, assembly language, etc. Different programmingtechniques can be employed such as procedural or object oriented. Anyparticular routine can execute on a single computer processing device ormultiple computer processing devices, a single computer processor ormultiple computer processors. Data may be stored in a single storagemedium or distributed through multiple storage mediums, and may residein a single database or multiple databases (or other data storagetechniques). Although the steps, operations, or computations may bepresented in a specific order, this order may be changed in differentembodiments. In some embodiments, to the extent multiple steps are shownas sequential in this specification, some combination of such steps inalternative embodiments may be performed at the same time. The sequenceof operations described herein can be interrupted, suspended, orotherwise controlled by another process, such as an operating system,kernel, etc. The routines can operate in an operating system environmentor as stand-alone routines. Functions, routines, methods, steps andoperations described herein can be performed in hardware, software,firmware or any combination thereof.

Embodiments described herein can be implemented in the form of controllogic in software or hardware or a combination of both. The controllogic may be stored in an information storage medium, such as acomputer-readable medium, as a plurality of instructions adapted todirect an information processing device to perform a set of stepsdisclosed in the various embodiments. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement insoftware programming or of the steps, operations, methods, routines orportions thereof described herein, where such software programming orcode can be stored in a computer-readable medium and can be operated onby a processor to permit a computer to perform any of the steps,operations, methods, routines or portions thereof described herein. Theinvention may be implemented by using software programming or code inone or more general purpose digital computers, by using applicationspecific integrated circuits, programmable logic devices, fieldprogrammable gate arrays, optical, chemical, biological, quantum ornanoengineered systems, components and mechanisms may be used. Ingeneral, the functions of the invention can be achieved by any means asis known in the art. For example, distributed or networked systems,components and circuits can be used. In another example, communicationor transfer (or otherwise moving from one place to another) of data maybe wired, wireless, or by any other means.

A “computer-readable medium” may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, system ordevice. The computer readable medium can be, by way of example, only butnot by limitation, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, system, device, orcomputer memory. Such computer-readable medium shall generally bemachine readable and include software programming or code that can behuman readable (e.g., source code) or machine readable (e.g., objectcode).

A “processor” includes any, hardware system, mechanism or component thatprocesses data, signals or other information. A processor can include asystem with a general-purpose central processing unit, multipleprocessing units, dedicated circuitry for achieving functionality, orother systems. Processing need not be limited to a geographic location,or have temporal limitations. For example, a processor can perform itsfunctions in “real-time,” “offline,” in a “batch mode,” etc. Portions ofprocessing can be performed at different times and at differentlocations, by different (or the same) processing systems.

It will also be appreciated that one or more of the elements depicted inthe drawings/figures can also be implemented in a more separated orintegrated manner, or even removed or rendered as inoperable in certaincases, as is useful in accordance with a particular application.Additionally, any signal arrows in the drawings/figures should beconsidered only as exemplary, and not limiting, unless otherwisespecifically noted.

Furthermore, the term “or” as used herein is generally intended to mean“and/or” unless otherwise indicated. As used herein, a term preceded by“a” or “an” (and “the” when antecedent basis is “a” or “an”) includesboth singular and plural of such term (i.e., that the reference “a” or“an” clearly indicates only the singular or only the plural). Also, asused in the description herein, the meaning of “in” includes “in” and“on” unless the context clearly dictates otherwise.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any component(s) thatmay cause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as a critical, required, or essentialfeature or component.

What is claimed is:
 1. A system for a distribution manager comprising: adistribution manager coupled to a network, including: a processor; and acomputer readable medium comprising instructions configured to: receivea request for support for a mobile application; determine a platformserver to support the mobile application based on capacity dataassociated with a set of platform servers in an application tableassociated with the mobile application; and deliver an identification ofthe platform server over the network, wherein the identification of theplatform server comprises connectivity information configured to allowthe mobile application to connect to the platform server.
 2. The systemof claim 1, wherein the request for support is received after a timeperiod has elapsed or connectivity between the mobile application andthe platform server cannot be established.
 3. The system of claim 2,wherein if connectivity between the mobile and the platform servercannot be established the instructions are configured to determine a newplatform server to support the mobile application.
 4. The system ofclaim 1, wherein the capacity data is associated a total number of userseach platform server within the set can support and a number of usersassigned to each platform server within the set.
 5. The system of claim1, wherein the instructions are further configured to: create a newplatform server if a capacity threshold associated with the platformserver and the capacity data is exceeded.
 6. The system of claim 1,wherein the instructions are further configured to: deprecate a platformserver within the set of platform servers based on the capacity data forthe set of platform servers.
 7. The system of claim 1, wherein theinstructions are further configured to: determine that a version of themobile application is not the most up to date version of the mobileapplication; and deliver an update of the mobile application.
 8. Thesystem of claim 1, wherein the request includes a device identifier, andinstructions are further configured to: compare the device identifierwith identifiers within the application table to determine whether toassign the platform server to the mobile application.
 9. A method for adistribution manager comprising: receiving a request for support for amobile application; determining a platform server to support the mobileapplication based on capacity data associated with a set of platformservers in an application table associated with the mobile application;and delivering an identification of the platform server over thenetwork, wherein the identification of the platform server comprisesconnectivity information configured to allow the mobile application tothe platform server.
 10. The method of claim 9, wherein the request forsupport is received after a time period has elapsed or connectivitybetween the mobile application and the platform server cannot beestablished.
 11. The method of claim 10, wherein if connectivity betweenthe mobile and the platform server cannot be established, determining anew platform server to support the mobile application.
 12. The method ofclaim 9, wherein the capacity data is associated a total number of userseach platform server within the set can support and a number of usersassigned to each platform server within the set.
 13. The method of claim9, further comprising: creating a new platform server if a capacitythreshold associated with the platform server and the capacity data isexceeded.
 14. The method of claim 9, further comprising: deprecating aplatform server within the set of platform servers based on the capacitydata for the set of platform servers.
 15. The method of claim 9, furthercomprising: determining that a version of the mobile application is notthe most up to date version of the mobile application; and delivering anupdate of the mobile application.
 16. The method of claim 9, wherein therequest includes a device identifier, and comparing the deviceidentifier with identifiers within the application table to determinewhether to assign the platform server to the mobile application.
 17. Anon-transitory computer readable medium, comprising instructions for:receiving a request for support for a mobile application; determining aplatform server to support the mobile application based on capacity dataassociated with a set of platform servers in an application tableassociated with the mobile application; and delivering an identificationof the platform server over the network, wherein the identification ofthe platform server comprises connectivity information configured toallow the mobile application to the platform server.
 18. The computerreadable medium of claim 17, wherein the request for support is receivedafter a time period has elapsed or connectivity between the mobileapplication and the platform server cannot be established.
 19. Thecomputer readable medium of claim 18, wherein if connectivity betweenthe mobile and the platform server cannot be established, determining anew platform server to support the mobile application.
 20. The computerreadable medium of claim 17, wherein the capacity data is associated atotal number of users each platform server within the set can supportand a number of users assigned to each platform server within the set.